home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 784 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.9 KB
  1. Path: newshost.netinfo.com.au!usenet
  2. From: Alan Brain <aebrain@dynamite.com.au>
  3. Newsgroups: comp.lang.ada,comp.lang.c++,comp.lang.c,comp.lang.modula3,comp.lang.modula2,comp.edu,comp.lang.eiffel
  4. Subject: Re: Hungarian notation
  5. Date: 7 Jan 1996 02:53:41 GMT
  6. Organization: Netinfo Pty Ltd - Canberra Australia
  7. Message-ID: <4cncjl$8nq@fred.netinfo.com.au>
  8. References: <30C40F77.53B5@swsbbs.com> <marnoldDJEvtJ.1Lx@netcom.com> <4aleun$jlk@ns.RezoNet.NET> <marnoldDJMDBG.CFz@netcom.com> <4asnkr$7b0@solutions.solon.com> <4ath75$e7i@barnacle.iol.ie> <4b4kij$svt@news.microsoft.com> <dewar.819489496@schonberg> <DK6r6I.Itr@eskimo.com>
  9. NNTP-Posting-Host: dialup6.dynamite.com.au
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.2N (Windows; I; 16bit)
  14.  
  15. mag@eskimo.com (mAg) wrote:
  16.  
  17. >Sorry, I cannot agree with you. Hungarianizing the variable names, function names etc. is extremely 
  18. >useful when you are working in team of 20+ programmers working on a huge project with say 40+MB of 
  19. >source code.
  20. >
  21. >>This is reminiscent of old batch style COBOL variable naming rules, and our
  22. >>experience at Realia was that people abandoned these naming conventions
  23. >>as soon as decent tools were available.
  24. >>'
  25. >
  26. >It is not practical to use these so called tools in large projects, Also for the sake of finding a 
  27. >variable in a large function, it helps to have a variable tell about itself in its name.
  28. >
  29. >We at work, use the following naming scheme :
  30. >
  31. >a : array
  32. >b : true or false (Boolean)
  33. >by: byte (8 bit long)
  34. >c : char
  35. >d : difference like dX, dY etc.
  36. >e : enum
  37. >f : float
  38. >g_: global or extern
  39. >h : handle (under Windows etc)
  40. >i : integer (as passed in parameter to a function)
  41. >j : integer (local variable)
  42. >l : long
  43. >m_: member variable (under c++)
  44. >p : pointer
  45. >q : pointer to a function
  46. >r : double
  47. >s : string if an array otherwise a pc (pointer to char)
  48. >u : unsigned
  49. >v : dword (32 bit long) int
  50. >w : word (16 bit long) int
  51. >
  52. >And trust me, it helps a lot in deciphering and fixing code by your colleague who broke the program 
  53. >just before going on christmas vacation. :-)
  54.  
  55. I tend to agree with you. BUT only in context. If you're using C, CMS-2Y 
  56. or any such similar language with a very low/nonexistent level of 
  57. abstraction, it's vital that you are easily able to see the exact 
  58. representation of the variable, otherwise you cannot manipulate it.
  59. Be aware of the fact that you're laying time-bombs which will explode 
  60. messily during the system's lifetime, as comments and variable names no 
  61. longer are accurate. But IMHO you have to live with that.
  62.  
  63. Should you be using any high-level language. you'd just get all the 
  64. disbenefits, and none of the benefits - so HN in any high-level language 
  65. is not just useless, it's shooting yourself in the foot. It's horse for 
  66. courses.
  67.  
  68. Again IMHO any code that's 40 meg or more is a great candidate for a 
  69. high-level language, but I'm showing my religion here.
  70.  
  71.  
  72.